- Acoplamiento fuerte: Las clases cliente dependen de clases específicas. Cambiar una clase obliga a modificar todas las que la consumen.
- Código difícil de testear: No se pueden crear objetos simulados (mocks o stubs). Las pruebas unitarias requerirán conexiones reales a bases de datos o servicios externos.
- Rigidez ante el cambio: Si necesitas reemplazar un proveedor de servicios (por ejemplo, cambiar el procesador de pagos), tendrás que reescribir gran parte del código base.
- Baja reutilización: Las clases quedan encasilladas en un único contexto técnico. No puedes reutilizar la lógica de negocio con diferentes tecnologías.
- Infracción del Principio Abierto/Cerrado: El código no queda "abierto a la extensión pero cerrado a la modificación". Cada nueva funcionalidad exige romper y editar el código existente.
- Dificultad en el trabajo en equipo: Los desarrolladores no pueden trabajar en paralelo. Un programador no puede avanzar en la lógica de negocio hasta que el otro termine la base de datos.
Explicación completa generada por IA:
